Re: easy way to acquire height / width from images (PNG, JPEG) stored as bytea?

> it killed my 200+ days uptime FreeBSD box :( .
> As I describe above, those attachments are nowhere as files.
> They are email attachments. Also we got about half TB of them.

it is possible - that some image is a "decompression bomb" ?

*"Because of the efficient compression method used in Portable Network
Graphics (PNG) files, a small PNG file can expand tremendously, acting as a
"decompression bomb". Malformed PNG chunks can consume a large amount of
CPU and wall-clock time and large amounts of memory, up to all memory
available on a system, causing a Denial of Service (DoS). Libpng-1.4.1 has
been revised to use less CPU time and memory, and provides functions that
applications can use to further defend against such files."*
https://libpng.sourceforge.io/decompression_bombs.html
https://stackoverflow.com/questions/33602308/how-to-check-png-file-if-its-a-decompression-bomb

Regards,
Imre

Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com> ezt írta (időpont: 2020.
ápr. 17., P, 16:39):

> On 17/4/20 4:09 μ.μ., Adam Brusselback wrote:
>
> Why not extract and store that metadata with the image rather than trying
> to extract it to filter on at query time? That way you can index your
> height and width columns to speed up that filtering if necessary.
>
> Yes I thought of that, but those are coming automatically from our mail
> server (via synonym), we have written an alias : a program that parses and
> stores emails. This is generic, I wouldn't like to add specific code (or
> specific columns) just for image attachments. However I dig the idea of
> the indexes.
>
> You may be able to write a wrapper for a command line tool like imagemagic
> or something so you can call that from a function to determine the size if
> you did want to stick with extracting that at query time.
>
> As I describe above, those attachments are nowhere as files. They are
> email attachments. Also we got about half TB of them.
>