From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id A97A246250 for ; Wed, 10 May 2023 14:01:40 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 14EB168BE2C; Wed, 10 May 2023 17:01:38 +0300 (EEST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B054968B263 for ; Wed, 10 May 2023 17:01:31 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 17B08C0003 for ; Wed, 10 May 2023 14:01:30 +0000 (UTC) Date: Wed, 10 May 2023 16:01:30 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230510140130.GB1391451@pb2> References: <20230506132503.9524-1-michael@niedermayer.cc> <20230508223508.GW1391451@pb2> <168361317605.3843.15085974109463921278@lain.khirnov.net> <20230509204402.GA1391451@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 1/3] avformat/dashdec: fail on probing non mpd file extension X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============6173698365982847782==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6173698365982847782== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5wdX5gfZV4kojQYf" Content-Disposition: inline --5wdX5gfZV4kojQYf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 10, 2023 at 08:44:31AM +0200, Tobias Rapp wrote: > On 09/05/2023 22:44, Michael Niedermayer wrote: >=20 > > 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. > > >=20 > > > 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 > >=20 > > Its for probing but IMHO > > If you have a > > taxreport.pdf that parses correctly as jar and installs jRAT if you exe= cute it > > Then it would be valid for probe() to identify this as type exploit ins= tead > > of type jar. And doing so would be more secure. > >=20 > > 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. > >=20 > > thx > >=20 > > [...] >=20 > 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 funct= ion > just doesn't know what the application expects. Expectation and actual in= put > 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 =66rom another direction, i think this viewpoint while true is too much going to special case optimization.=20 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 [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle --5wdX5gfZV4kojQYf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZFujtQAKCRBhHseHBAsP q/oFAJ9Z/7TogrkCwTPMah4Scjs0SQ8k3wCbB0UTOBgEah4qJjuKQ0D2rij3f4k= =rI/T -----END PGP SIGNATURE----- --5wdX5gfZV4kojQYf-- --===============6173698365982847782== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============6173698365982847782==--