search for: aitap

...t untrusted *.rds or *.rda files, R-4.4.0 or any other version of R will be of no help to you. There are too many ways to make an R object dangerous to use, and the *.rds and *.rda files will faithfully represent the trapped R object even in the absence of any vulnerabilities in the parser: https://aitap.github.io/2024/05/02/unserialize.html If you only process *.rds and *.rda files you trust, you've never been in danger from this so-called vulnerability. Feel free to keep running older versions of R. -- Best regards, Ivan

...'s C API guarantees it won't return null pointers? The only > reference I found in the "Writing R Extensions" manual where this not > the case is `R_tryEval` and `R_tryEvalSilent`. Based on what I've been reading while working on (still very much incomplete) <https://aitap.codeberg.page/R-api>, I think that these are the only two cases where a SEXP can be null, precisely because a null pointer is distinguished from every possible value that could be returned by eval(). Some APIs may accept a null SEXP (with comments in the source code that this is to support some...

...obably should not be <...> used". Do you think there is a way to recreate an environment, taking the REFSXP entries into account, without `parent.env<-`? Would you recommend to abandon the folly of unserializing environments manually? -- Best regards, Ivan [1] https://codeberg.org/aitap/unserializeData/src/commit/33d72705c1ee265349b3e369874ce4b47f9cd358/R/unserialize.R#L289-L313

...l(depcache:::C_hash2, b) # [1] 44 21 f1 36 5d 92 03 1b ...but that's unavoidable when looking at frozen object contents instead of their live memory layout. If you're interested, here's the development version of the package: install.packages('depcache',contriburl='https://aitap.github.io/Rpackages') -- Best regards, Ivan [*] https://github.com/aitap/depcache/blob/serialize_canonical/src/serialize.c [**] https://svn.r-project.org/R/trunk/doc/notes/immbnd.md

...iles, R-4.4.0 or any other version of R will be of no help to you. There are too many ways to make an R object dangerous to use, and the *.rds and *.rda files will faithfully represent the trapped R object even in the absence of any vulnerabilities in the parser: https://urldefense.com/v3/__https://aitap.github.io/2024/05/02/unserialize.html__;!!LpKI!hEQ5oMp6_ra80HnvSAfdgKZt9ARNgbyOd8c5YyJFuWpSxoe_KV5GJppNJH1qabGv0xeYnGuABnLkherDiCFt$ [aitap[.]github[.]io] If you only process *.rds and *.rda files you trust, you've never been in danger from this so-called vulnerability. Feel free to keep runni...

...t won't return null pointers? The only > > reference I found in the "Writing R Extensions" manual where this not > > the case is `R_tryEval` and `R_tryEvalSilent`. > > Based on what I've been reading while working on (still very much > incomplete) <https://aitap.codeberg.page/R-api>, I think that these are > the only two cases where a SEXP can be null, precisely because a null > pointer is distinguished from every possible value that could be > returned by eval(). > > Some APIs may accept a null SEXP (with comments in the source code tha...

...avoid recursive calls to findInheritedMethods." -- Best regards, Ivan [1] https://stat.ethz.ch/pipermail/r-package-devel/2024q3/011097.html [2] https://github.com/r-devel/r-svn/blob/776045d4601ed3ac7b8041e94c665bbfe9709191/src/library/methods/R/methodsTable.R#L457 [3] https://codeberg.org/aitap/S4_vs_onLoad

...null pointers? The only >>> reference I found in the "Writing R Extensions" manual where this not >>> the case is `R_tryEval` and `R_tryEvalSilent`. >> >> Based on what I've been reading while working on (still very much >> incomplete) <https://aitap.codeberg.page/R-api>, I think that these are >> the only two cases where a SEXP can be null, precisely because a null >> pointer is distinguished from every possible value that could be >> returned by eval(). >> >> Some APIs may accept a null SEXP (with comments in...

On Thu, Apr 25, 2024 at 4:24?AM Ivan Krylov via R-devel <r-devel at r-project.org> wrote: > > On Wed, 24 Apr 2024 15:31:39 -0500 (CDT) > luke-tierney--- via R-devel <r-devel at r-project.org> wrote: > > > We would be better off (in my view, not necessarily shared by others > > in R-core) if we could get to a point where: > > > > all entry points

Could you recommend any packages/functions that compute hash such that the source references and sexpinfo_struct are ignored? Basically a version of `serialize` that convert R objects to raw without storing the ancillary source reference and sexpinfo. I think most people would think of `digest` but that package uses `serialize` (see discussion

On Sat, 11 May 2024, Peter Langfelder wrote: > On Sat, May 11, 2024 at 9:34?AM luke-tierney--- via R-devel > <r-devel at r-project.org> wrote: >> >> On Sat, 11 May 2024, Travers Ching wrote: >> >>> The following code snippet causes R to hang. This example might be a >>> bit contrived as I was experimenting and trying to understand >>>

Dear R Foundation Team, I hope this message finds you well. I am reaching out to seek your guidance on addressing the security vulnerability CVE-2024-27322. As I understand, a security fix for this vulnerability has been available starting from v4.4.0. This issue affects all versions from 1.4.0 to 4.3.3. During our testing phase, we encountered a challenge while attempting to upgrade to the

Hello, I'm working on bindings for the API (for zig), and was wondering if the R's C API guarantees it won't return null pointers? The only reference I found in the "Writing R Extensions" manual where this not the case is `R_tryEval` and `R_tryEvalSilent`. Otherwise it's unclear. The reason I care about this is syntax. Because I don't know whether SEXPs are NULL or

...1] 44 21 f1 36 5d 92 03 1b > > ...but that's unavoidable when looking at frozen object contents > instead of their live memory layout. > > If you're interested, here's the development version of the package: > install.packages('depcache',contriburl='https://aitap.github.io/Rpackages') > > -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall...

All, There seems to be a hullaboo about a vulnerability in R when deserializing untrusted data: https://hiddenlayer.com/research/r-bitrary-code-execution https://nvd.nist.gov/vuln/detail/CVE-2024-27322 https://www.kb.cert.org/vuls/id/238194 Apparently a fix was made for R 4.4.0, but I see no mention of it in the changes report: https://cloud.r-project.org/bin/windows/base/NEWS.R-4.4.0.html

...eturn value are both either TRUE or FALSE. Martin > [1] https://stat.ethz.ch/pipermail/r-package-devel/2024q3/011097.html > [2] https://github.com/r-devel/r-svn/blob/776045d4601ed3ac7b8041e94c665bbfe9709191/src/library/methods/R/methodsTable.R#L457 > [3] https://codeberg.org/aitap/S4_vs_onLoad