]] 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" <paul...@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2siyoqa93....@rahvafeir.err.no
