Reposting in the correct thread: The other alternative, I suppose, is to have no limits by default, and apps that wish to be "safe" need to proactively make a call to set up the guardrails. But then you have to trust the majority of apps to set it, and to do so sensibly (or risk not having any input sensibility validation in place), rather than trusting just the very few who need higher limits to know how to raise the controls.
Things like this are of growing concern to all our popular open source libraries (not just OIIO), especially the ones successful enough to make their way into commercial apps, cloud services, etc. -- those vendors become paranoid (and rightfully so) that the library becomes an attack surface that makes the whole app or service vulnerable to maliciously crafted input. The few people who are out there looking for and exploiting every possible way to subvert the software stack are really making life complicated and miserable for the rest of us. This is why we can't have nice things. > On Dec 4, 2021, at 12:30 PM, Larry Gritz <[email protected]> wrote: > > I'm thinking something like this: > > $ oiiotool bad.tif -o out.tif > oiiotool ERROR: read : "bad.tif": Uncompressed image size 52127 MB exceeds > "limit:imagesize_MB" = 32768. Possible corrupt input? > If you're sure this is a valid file, raise the OIIO global attribute > "limit:imagesize_MB". > > >> On Dec 4, 2021, at 11:07 AM, Thomas Mansencal <[email protected] >> <mailto:[email protected]>> wrote: >> >> > it's on you to warn OIIO that this is the kind of legit data you are >> > expecting. >> >> Are you considering to warn the user beforehand though in case he tries to >> pass such image? Be annoying to have the library starting to silently fail >> all of sudden. >> >> On Sun, 5 Dec 2021 at 7:21 AM, Larry Gritz <[email protected] >> <mailto:[email protected]>> wrote: >> For what I'm thinking about, one can raise the limit with a call to the >> library (or have no limit at all). So if you're dealing with a research >> renderer with one channel per nm of spectrum, maybe it's on you to warn OIIO >> that this is the kind of legit data you are expecting. >> >> I'm hoping to find a reasonable default where the likelihood is very high >> that more than that number of channels indicates bad input, and only >> advanced users who know that they are in this situation ever need to know >> about and alter the option. >> >> 10 is too low -- although most people write AOVs to different files or at >> least different parts of a multi-image file, I know some users have dozens >> of channels crammed into one part/subimage. >> >> 1000000 is too high, that surely indicates a broken or malicious file. >> >> Somewhere in the middle is the right limit. >> >> And similarly, I'm also thinking about a maximum memory size for a single >> flat 2D image as a sanity check to avoid being "tricked" into a memory >> allocation that will fail (again, a limit you can override if you know such >> images are coming). I'm thinking 4GB as the default. Does that sound >> reasonable? Too low? What about 32GB (that's 64k x 64k x 4 chan x >> sizeof(half))? >> >> >>> On Dec 4, 2021, at 9:55 AM, Thomas Mansencal <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Larry, >>> >>> With a spectral renderer, assuming storage every nanometers, 400+ >>> irradiance channels are totally plausible. This is more a research case >>> though, e.g. Mitsuba 2, but it is possible to see where this goes as soon >>> as you start combining that with AOVs, e.g. spectral direct vs spectral >>> indirect, per-light contribution, etc… >>> >>> Cheers, >>> >>> Thomas >>> >>> On Sat, 4 Dec 2021 at 9:47 PM, Larry Gritz <[email protected] >>> <mailto:[email protected]>> wrote: >>> What's the highest number of color channels you've seen in a single legit >>> image file? >>> >>> If we wanted to have a limit of the number of channels, over which we would >>> conclude that a file was highly likely to be corrupt or even malicious... >>> what is a reasonable limit? Is 1024 too low? >>> >>> (Assume there is a runtime way to override this limit, in the unlikely case >>> that a legit file needs more than this number of channels.) >>> >>> >>> -- >>> Larry Gritz >>> [email protected] <mailto:[email protected]> >>> >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>> -- >>> Thomas Mansencal - colour-science.org <https://www.colour-science.org/> - >>> thomasmansencal.com >>> <http://www.thomasmansencal.com/>_______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> >> -- >> Larry Gritz >> [email protected] <mailto:[email protected]> >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> -- >> Thomas Mansencal - colour-science.org <https://www.colour-science.org/> - >> thomasmansencal.com >> <http://www.thomasmansencal.com/>_______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
