Re: [FFmpeg-devel] [PATCH 1/3] avformat/dashdec: fail on probing non mpd file extension

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 2587 bytes --]

On Wed, May 10, 2023 at 08:44:31AM +0200, Tobias Rapp wrote:
> On 09/05/2023 22:44, Michael Niedermayer wrote:
> 
> > On Tue, May 09, 2023 at 08:19:36AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-05-09 00:35:08)
> > > > [...]
> > > > would anyone be opposed to return 0 from dash_probe() when
> > > > both the mime_type and the extension are wrong ?
> > > I would.
> > > 
> > > probe() is for probing, not implementing security policies. IMO trying
> > > to fix security issues at the wrong layer will only lead to more
> > > confusion, more complexity, and LESS security.
> > YES i agree, probe is not for security policies
> > 
> > Its for probing but IMHO
> > If you have a
> > taxreport.pdf that parses correctly as jar and installs jRAT if you execute it
> > Then it would be valid for probe() to identify this as type exploit instead
> > of type jar. And doing so would be more secure.
> > 
> > This is really more along the line of thought here for hls too.
> > a file with avi/mkv/mov/mxf/mpg/mp4 extension is not a hls playlist
> > Could someone have added that extension by mistake, yes
> > similarly your jar file could be named .pdf by mistake. But thats not
> > a good default assumtation and i dont think anyone would assume that
> > by default.
> > 
> > thx
> > 
> > [...]
> 
> But if the application expects a HLS playlist would it really be a problem
> if the input file ends with .avi or some other extension? The probe function
> just doesn't know what the application expects. Expectation and actual input
> type are aligned after probe.

if the application is just for hls then sure you are correct but then also
why would the application even run probe ? it would be a waste of cpu cycles

from another direction, i think this viewpoint while true is too much
going to special case optimization. 

Maybe we can factor the hls probe in 2 cases. One would be
unambiguous hls (mime/extension content all matching)
ambigous hls (mime/extension not correct or maybe some very odd URLS in it but otherwise valid hls)

This would not loose any detected files but would give more details
to user apps and users to make the choice.
a user or app could then simply include or not include the ambigous hls
in the format whitelist or blacklist
This would also not complicate the API but just use the existing features

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".