Laurence Parry wrote...

> It was assumed that the version number would remain below 32 "for the time
> being". This time has passed. Version 32 was published in May 2016, and it
> is already up to 34:
> We detected this issue when our web application refused an SWF file created
> by an animator.

Thanks for the catch, although this is rather bad news for the file
program. As any value from 32 on is a printable character, there will
always be a risk of mis-detection.

> Alternatives which would preserve the fix for #745546 might be to permit
> versions below 48 ('0') or 65 ('A'), and/or to test for a sane length, e.g.
> 0       string          CWS             Macromedia Flash data (compressed),
> >3      byte            x               version %d,
> >>4     lelong          <0x20000000     length %d bytes
> !:mime  application/x-shockwave-flash
> This refuses a 512MB compressed Flash file. I am not aware of anyone who's
> created such a file, but it is technically possible (e.g. Flash games with
> very large embedded flash videos).

I'm not really happy about this and could use more ideas. Assuming you
have a major collection to such files, is there anything in the
following header octets (FrameSize, FrameRate, FrameCount) that
somewhat certainly is not printable?


Attachment: signature.asc
Description: Digital signature

Reply via email to