On 17/4/20 6:14 μ.μ., Imre Samu wrote:
> 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
Thank you a lot Imre. Great info.
Achilleas Mantzios <ach...@matrix.gatewaynet.com
<mailto:ach...@matrix.gatewaynet.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.
