Skip to content

[R-pkg-devel] Example files for functions reading binary files

4 messages · Rafael Ayala Hernandez, Josiah Parry, Ivan Krylov +1 more

Original
Rafael Ayala Hernandez
# 
ello,

I have added some functions to read binary files in my asteRisk package. The binary files that are read contain just arrays of coefficients and metadata about these.

I would like to provide a small file of these to be used in the examples of the man page for the functions that read them. However, section 1.1 of "Writing R Extensions? states that no binary files are accepted in submissions to CRAN (https://cran.r-project.org/doc/manuals/R-exts.html)

I was wondering if it would be acceptable to download the example file to a temporary file in the example themselves (and in fact, also in unit tests), and then read it from there?

I could not find any statement against this in ?Writing R Extensions?, but I would like to confirm that this is OK to do before submitting an updated version of the package to CRAN.

Thanks a lot in advance

Best wishes,

Rafa
Josiah Parry
# 
Rafael,

I believe the issue is that packages cannot include binary *executables.* If
you have a binary file (such as a parquet file) in inst/extdata, I do not
think that would be a problem. It would be a good idea to ensure that that
file is small, though. I think downloading a file is a big no no to be ran
on CRAN machines. I would personally advise against downloading anything.

On Sun, Dec 3, 2023 at 9:54?AM Rafael Ayala Hernandez <
Rafael.AyalaHernandez at oist.jp> wrote:

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Ivan Krylov
    

    

      
      #
    

  


  

      
On Sun, 3 Dec 2023 09:33:30 +0000

        
Rafael Ayala Hernandez <Rafael.AyalaHernandez at oist.jp> wrote:

        

            

      
      
      
    

        
Files can be "binary" in multiple different senses. Your files are
binary in the sense that they contain data not in a plain text format.
This usage is fine. PNG images and files produced by save() or
saveRDS() are binary in this sense too.

Files can also be "binary" in the sense that they are not
human-readable source code for a computer program, but compiled
executable code. *.exe's and *.dll's, *.so's and *.dylib's, and also
*.jar files are binaries in this sense. The reason they are forbidden
is because they are much harder to inspect than the source code they
have been compiled from.

It's not always so clear-cut, though. One example is R's own
serialization format where one could save a function and later restore
and run it. If R did not allow this, it would be much less convenient
to use, despite being slightly more secure. In another example, due to
a vulnerability, a binary data file (or even a text file, say, a
JavaScript program) may contain an encoded computer program that the
data-reading program will execute instead of reading it due to being
confused. (E.g. jailbreak.me used to confuse iPhones into overwriting
parts of their firmware despite that's normally not allowed for a
website.)

It is important to write parsers for binary and text files so that even
if these files are produced by an adversary, the program reading them
will not be tricked into executing program code stored inside. You
should be mostly safe if you're doing this in pure R (or else R may
need to be fixed).

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
On 03.12.2023 16:12, Josiah Parry wrote:

            

      
      
      
    

        
Same from here:
meant are files containing executable code such as shared or statically 
linked libraries, executables etc.
Binary data files are permitted.

Best,
Uwe Ligges