[ic] [interchange] Revert "Add image file check mechanism to verify file type before passing to"

David Christensen david at endpoint.com
Sat May 14 15:15:16 UTC 2016


> On May 14, 2016, at 9:37 AM, Mike Heins <mikeh at endpoint.com> wrote:
> 
>>>>    Per discussion, this is not Interchange's responsibility.
>>>> 
>>> Since the image tag does call "mogrify", I would argue that it is the Image tag's responsibility.
>> 
>> Anyone who would update Interchange from git to fix this would already
>> have the chops to fix the root problem anyway. This is an
>> education/awareness issue, not something we should be working around.
>> We aren't rolling our own TLS layer to fix Heartbleed, for instance.
>> Why is this any different?
> 
> Because it makes sense, for all sorts of data integrity reasons, to limit
> a program's input to that which it is intended to service. It is true that
> the spur is a security issue, but the end is noble in and of itself.

> The only downside would be a limitation of the program, which might be
> able to handle unanticipated image types, but at this point the universe
> of those types is pretty static.

The patch as written was broken and caused image.tag to not compile when missing Image::Size (which is apparently only in Bundle::InterchangeKitchenSink); in any case, the demo site broke because it did not have this module.  This was the motivator for the investigation and further discussion around how (or if) to fix this.  (Had this not been the case, I likely would have ignored the patch. :-))

I think the ecosystem of various parts here is too large to take this approach with everything; *particularly* since it’s a separate external program, I think it’s the external tool’s responsibility to vet its own input.  If we were using low-level graphics libraries inside Perl to handle all the manipulations or even the Image::Magick module directly (again, within Perl) I would say our code has a responsibility to check things like return codes, formats, etc.  But it just seems like we’re committing to more than we should at this point.

David
--
David Christensen
End Point Corporation
david at endpoint.com
785-727-1171






More information about the interchange-users mailing list