Re: We need a global decision about R data in binary format, and stick to it.

[Tollef Fog Heen <tfheen@err.no>]

]] Ian Jackson 

> Bastien ROUCARIES writes ("Re: We need a global decision about R data in binary format, and stick to it."):
> > Le 5 août 2013 15:42, "Paul Tagliamonte" <paultag@debian.org> a écrit :
> > > IMVHO, this is the same as how we should treat images (I mean, for any
> > > data format, not just this one case of a pickled object) - if the image
> > > was a photo, clearly the .jpg or .png or whatever we get is the best way
> > > to communicate this data, but if the image was generated off an .svg,
> > > it should be distributed with it (and even rebuilt at build-time).
> > 
> > Could we made an exception for specially crafted image in order to exercice
> > buffer oveeflow ? (I think particularly art libpng ImageMagick)
> 
> I think this is something of a red herring corner case, and not really
> related to the question about R binary objects.

Agreed.

> If the last thing that happened to the image file was that upstream
> edited it with a hex editor to introduce a buffer overflow, then the
> resulting binary file is the preferred form for modification (after
> all, that's how the last person to do so modified it...)

Or more precisely, it's no longer an image that you tend to use for,
well, displaying something.  It's a test for a buffer overflow that also
happens to be an image.  (Saying that just because somebody last edited
a file with a hex editor then that's the preferred form for modification
leaves a pretty large hole.  If I make a change to a blob and change a
2012 to 2013 in a copyright notice, it's obvious that the blob isn't its
own source.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are